A single IC may include millions of individual devices, such as transistors, capacitors, and resistors, formed on one chip to perform desired functions. Production of such complex ICs is an intricate process that involves many steps. One of the first steps in producing an IC involves designing a virtual version of the IC using computer-aided design tools. The design of a virtual version of an IC can be broken down into three general areas: design definition, design verification, and design layout. IC design definition can be described at various levels of sophistication or detail. The levels of design sophistication include the functional level, also referred to as the register transfer level (RTL) or the architectural level; the logical level, also referred to as the gate level; and the transistor level, also referred to as the layout level.
Known design environments commonly utilized at the functional design level involve one of two major hardware design languages, Verilog or VHDL. To minimize the cost of design errors, the functional design of an IC is put through a verification process to identify and correct functional design problems before the IC is laid out and fabricated. An old technique for design verification involves performing a computer simulation of a virtual design of the IC and applying a known series of input data, also known as verification vectors, to the inputs of the IC. The simulation then simulates the expected outputs that the IC would physically generate. The design is verified by a design engineer studying the simulated outputs of the IC to determine if the IC is functioning correctly.
The described prior art technique of design simulation at the functional level requires a large volume of verification vectors. As the complexity of an IC grows, the volume of verification vectors grows exponentially in relation to the number of gates in the IC. This large volume of verification vectors is difficult to manage in terms of an engineer being able to generate the vectors and analyze the vectors. As IC designs and IC verification have grown more complex, the task of generating and analyzing verification vectors is being replaced by more automated processes.
A known technique for generating, managing, and analyzing the growing volume of verification vectors involves including verification software in the simulation software. The verification software generates the verification vectors that are input into the virtual IC that is being simulated. In addition, the verification software examines the output of the virtual IC being simulated for correct behavior. The added verification software is often in the form of bus functional models. That is, the verification software simulated along with the IC mimics and verifies the correct functioning of buses that comprise inputs and outputs to the IC. A bus is a collection of signals that together carry data in and out of ICs. An interface to an IC is a collection of buses, data signals, and control signals that connect to the IC and together perform some data transfer operations in or out of the IC. A bus functional model is a software representation of an interface to an IC. A bus functional model typically interacts with an IC during a simulation by sending data to and receiving data from the IC during the simulation. Bus functional models can be written which send a large body of defined data to an IC, and they can also be written to verify that interfaces are receiving some expected data in a fashion that conforms to the specification of how the interface is supposed to operate. In this way, bus functional models can both generate and verify simulation vectors that are sent to and received from the simulated IC.
FIG. 1 is a high level representation of a simulation unit 10 that utilizes a bus function model 12 to interact with a virtual IC 14 during simulation. The bus functional model along with the IC being simulated together generate simulation results over the course of the simulation. The simulation results are then stored in a simulation results database 18 for future use. The simulation results typically flow from the simulation unit in a stream of data and then are stored in the database. FIG. 2 is an example of a waveform display of simulation results that includes a clock signal 30, three variables X, Y, and Z, and their associated variable values 32, 34, 36 as a function of time. As can be seen from the waveform display of FIG. 2, the waveforms do not easily identify the specific operations that are being performed at any point in time.
Although simulation results in some prior art simulations are broken down into bus functional models, there are many suboperations that occur during the operation of a bus functional model that cannot be readily located in a database or viewed for analysis. In addition, errors that occur during a simulation are hard to locate in a database or view for analysis. As a result, large volumes of simulation results are stored and viewed as one continuous group of verification vectors as shown in FIG. 2, thereby making the simulation results difficult to analyze and use for debugging.
In view of the large volume of simulation results that must be analyzed to detect and correct design flaws in the virtual design of an IC, what is needed is a method and apparatus that allow simulation results to be more easily analyzed.